AI Analysis Details Table

Default View

N/A

This is the most commonly used set of columns that provide a summary view of your containers. Significant wasted spend is highlighted. The "Total Waste" is pinned to the left side of the table and the table is sorted on this column in descending order.

All Data

N/A

All columns are displayed. All filters are cleared. Horizontal and vertical scroll bars are displayed so you can navigate the content of the table.

CPU Risks

CPU Request Shortfall

This view highlights containers with a shortfall of CPU resources.

CPU Request Shortfall (from Unspecified)

This view highlights containers with unspecified with CPU request values.

CPU Request Shortfall (Throttling Risk)

This view highlights containers with a shortfall of CPU resources.

Oversized CPU Limits

This view highlights containers with surplus CPU resources.

Undersized CPU Limits (Throttling Risk)

This view highlights containers that are sized incorrectly and are under CPU pressure. You can identify containers at risk and adjust their CPU allocation to prevent performance issue.

CPU Waste

CPU Request Surplus

This view highlights containers identified with surplus CPU request settings.

Immediate CPU Savings

This view highlights immediate savings that can be achieved by adjusting the CPU Request settings only for containers within Node Groups where the "CPU Request" is the primary constraint.

Additional CPU Waste

This table highlights possible, additional savings that can be achieved.

Memory Risks

Memory Request Shortfall

Memory Request Shortfall (from Unspecified)

This view highlights containers with unspecified with memory request values.

Memory Request Shortfall (OOM Risk)

Oversized Memory Limits

Undersized Memory Limits (OOM Risk)

This view highlights containers that are sized incorrectly and are under memory pressure. You can identify containers at risk and adjust their memory allocation to prevent service failures.

Memory Limit Events

This view highlights containers that have already experienced out of memory events.

Restarts

Memory Request Surplus

Immediate Memory Savings

Additional Memory Waste

This table highlights possible, additional savings that can be achieved.

Cluster

The parent cluster containing the pods.

Entity ID

A unique identifier, assigned by Densify.

Node Group

The name of any node groups contained in this cluster. If the cluster contains multiple node groups, all node groups are listed.

For nodes that do not belong to a node group, the node group value will be <cluster-name>-default”.

Namespace

The namespace associated with the container. This allows you to logically group your pods.

Pod Owner Kind

The controller type that monitors and maintains the state of your cluster. This can be one of DaemonSet, Deployment, ReplicaSet, ReplicationController, StatefulSet, etc.

Average No. of Containers

This is the average number of containers specified by the selected manifest.

The number is determined using an average number of containers, based on the metric, "In Service Instances".

The total number of containers, listed at the bottom of each column is based on your selection in the tree viewer and on any filters that have been applied.

This value is used to calculate surplus resources and savings/waste.

Pod Owner Name

This is the name of the controller or pod. You can have one or more containers per pod.

Container Name

This is the name of the container manifest.

The container name is a hyperlink that opens a summary view.

When you export the content of this table, a URL is provided in the last column, "Container Details URL". When you open the exported .XLS file, the content initially appears as plain text and then when you click on the cell it becomes a hyperlink that takes you to the Overview page for the selected container. See Using Deep Linksfor details.

Policy

This is the name of policy used to analyze this container's utilization data. Click the link to open a flyout summary of the policy settings.

Contact [email protected] for details on configuring policy settings.

CPU Request (mCores)

Memory Request (MB)

CPU Limit (mCores)

Memory Limit (MB)

The current request and limit CPU | memory values for the selected container are displayed in these 4 columns.

The total, listed at the bottom of the Request and Limit columns for both CPU and Memory, is calculated as (current value * No. of Containers). This formula is also used for CPU Limit and Memory Limit.

For containers where the current CPU value is unspecified a dash (-) is displayed in the main table and '0' is displayed in the "Total" row.

Recom. CPU Request (mCores)

Recom. Memory Request (MB)

Recom. CPU Limit (mCores)

Recom. Memory Limit (MB)

The recommended request and limit CPU | memory values for this container are displayed in these columns.

The total, listed at the bottom of the Request and Limit columns for both CPU and Memory, is calculated as (Current CPU Request * Current Count). This formula is also used for CPU Limit and Memory Limit.

These columns are hidden by default. You can enable it for display, as required. See Data Controls, above.

Surplus CPU Limit (mCores)

Surplus Memory Limit (MB)

The surplus is the difference between the current and the recommended values. If the current value is unspecified, then the surplus value will be negative (i.e. 0 - recommended value).

% CPU Request vs Required

This is the percentage of requested CPU as a percentage to the number of CPUs that are required.

% CPU Limit vs Required

This is the percentage of CPU resources allocated to limits as a percentage to the CPUs limit value required.

% Memory Request vs Required

This is the percentage of requested memory as a percentage to the amount of memory that is required.

% Memory Limit vs Required

This is the percentage of memory resources allocated to limits as a percentage to the memory limit value required.

Total CPU Request (mCores)

This is the total CPU request value for the container and is calculated as (current value * No. of Containers).

Total CPU Request Surplus from Unspecified (mCores)

The manifest does not specify a total CPU request, so the displayed value is based on the recommended setting. Because an unspecified request is treated as 0, the "surplus" appears as a negative value, indicating that the recommended CPU request is greater than zero.

This value is indicated as a shortfall on the Overview tab.

See 1 for more details.

Total Surplus CPU Request (mCores)

This is the total surplus CPU request value for the container and is calculated as: (Current CPU Request - Recommended CPU Request) * Uptime% * No. of Containers.

Total Memory Request (MB)

This is the total memory request value for the container.

Calculated as: (current value * No. of Containers).

For containers where the current CPU value is unspecified "0" is displayed in this column.

Total Memory Request Surplus from Unspecified (MB)

The manifest does not specify a total memory request, so the displayed value is based on the recommended setting. Because an unspecified request is treated as 0, the "surplus" appears as a negative value, indicating that the recommended memory request is greater than zero.

This value is indicated as a shortfall on the Overview tab.

See 1 for more details.

Total Surplus Memory Request (MB)

This is the total surplus memory request value for the containe.

Calculated as: (Current Memory Request - Recommended Memory Request) * Uptime% * No. of Containers.

For containers where the current CPU value is unspecified "0" is displayed in this column.

Uptime %

Uptime % is the total time the container has been running as a percentage of the total hours since the container was deployed. (Running Hrs/Total Hrs)

When using pay-per-use pricing models, the amount of time each instance has been running, is required to accurately estimate future costs.

The predicted uptime (%) for a cloud instance or container, is based on the percentage of hours CPU utilization data is present in the historical interval, as specified in the policy settings for the entity. For Auto Scaling groups and VM Scale Sets and Individual child instances are not taken into account.

, for new instances or containers, that started mid-way through the historical interval, is calculated from the time/date that the instance was started as opposed to the beginning of the interval, resulting in more accurate predictions for future usage.

For example, the uptime is the number of hours that have "CPU Utilization in mcores", and the range is the lesser of when the container was discovered, or the range defined in the policy. Looking at a specific container that was discovered on Jan 5th 2024, that has workload of 42 hours since that date, then the uptime % is 42 hrs/(13 days x 24 hrs/day) = 13.4%. This is the value shown in this column.

Total Hrs

The total hours are determined by calculating the duration from the time the first container, as defined by the manifest, starts, until the point that Densify analyzes the specified containers. Total hours continues to increment until the manifest is no longer discovered by Densify.

Running Hrs

Running hours is the number of hours of CPU utilization data from any running containers, as defined by the container manifest. The number of running containers is not used when determining the number of running hours. i.e. 3 containers are running from 2pm to 6pm, then “Running Hours” will be 4 hrs.

Restarts - Last Day

The total number of restarts of all containers associated with the deployment, in the last day.

A dash (-) is displayed if no data has been collected.

Memory Limit Event - Last Day

Indicates if the peak working set memory utilization was near or exceeded the memory limit, in the last day. If memory events have been encountered (value=Yes) then the table cell is shaded to clearly indicate this container is at risk.

A value of "No" indicates:

• There is data and no memory events have occurred;
• The current memory limit is unspecified for the selected container.

Optimization Type

Identifies the overall result of the optimization analysis.

Values are colour-coded and the possible colours are listed in Container Optimization Types, below.

Cost per Container ($/month)

This is the cost to run this container. The value is calculated as follows:

((Current CPU Request/1000) * CPU unit cost + (Current Memory Request/1024) * Memory unit cost) * Uptime%

Waste per Container ($/month)

This is the amount of money that can be saved by running this container, in the recommended configuration. The value is calculated as follows:

(((Current CPU Request - Recommended CPU Request)/1000) * CPU unit cost + ((Current Memory Request - Recommended Memory Request)/1024) * Memory unit cost) * Uptime%

Total Cost ($/month)

The total cost for the containers in the selected scope.

Calculated as Cost per Container * No. of Containers.

Immediate CPU Savings ($/month)

Immediate (Realizable) CPU savings can be achieved by optimizing specific CPU settings.

You can reduce costs, by adjusting the CPU Request settings, only for containers within NodeGroups where "CPU Request" is the primary constraint.

A container qualifies for immediate savings if the "% of Nodes with CPU Saturation" is below a predefined threshold. For example, if the threshold is set at 50%, only containers where "% of Nodes with CPU Saturation" is less than 50% should be considered.

Realizable memory savings can be achieved by adjusting the Memory Request settings only for containers within Node Groups where Memory Request" is the primary constraint.

Calculated as: (Sum (Total Surplus CPU Request (mCores))” /1000 mCores/Cores) * CPU unit cost.

Additional CPU Waste ($/month)

The total cost for the containers in the selected scope.

Calculated as: (Total Surplus CPU * CPU unit cost) - Immediate CPU Savings

Immediate Memory Savings ($/month)

Immediate (Realizable) memory savings can be achieved by optimizing specific memory settings.

Realizable memory savings can be achieved by adjusting the Memory Request settings, only for containers within Node Groups where Memory Request is the primary constraint.

A container qualifies for immediate savings if the "% of Nodes with CPU Saturation" is below a predefined threshold. For example, if the threshold is set at 50%, only containers where "% of Nodes with CPU Saturation" is less than 50% should be considered.

Calculated as: (Sum (Total Surplus Memory Request (MB)) /1024 MB/GB) * memory unit cost.

Additional Memory Waste ($/month)

The total cost for the containers in the selected scope.

Calculated as: (Total Surplus Memory * Memory unit cost) - Immediate Memory Savings

Total Realizable Savings ($/month)

Realizable (Immediate) savings can be achieved by optimizing specific CPU and memory settings.

Calculated as: Sum of Immediate CPU Savings + Sum of Immediate Memory Savings

Total Waste ($/month)

This value indicates the total savings that can be achieved if the recommendations are implemented.

Calculated as: (Waste per Container ($/month) * No of Containers

# of Nodes

This is the number of nodes on which this container has run.

You can hover over the cell to see the list of all node name(s) on which the selected container(s) reside(s).

Container Configuration Updated On

A value in this column indicates the instance type (cloud) or instance request/limit values (container) has been change recently.

The workload for this instance, on which the recommendation is based, includes only the days of data from the indicated date to the current date. All historical data for this instance, collected prior to the indicated date is not included in the analysis. Previous data has been excluded because it was based on the previous instance type (cloud) or instance request/limit values (container).

A blank cell indicates the current instance type has not changed and all available workload data within the range, defined by the policy, has been used to generate the recommendation.

Contact [email protected] to enable this feature.

Node Group CPU Saturation

Indicates whether this container resides on a node with CPU utilization above the saturation threshold (default: 95%), during the past 7 days.

The saturation threshold value is configurable. Contact [email protected] for details.

% Nodes with CPU Saturation

The percentage of nodes with peak CPU utilization above the configurable, saturation threshold (default: 0%) during the past 7 days of history. The value is expressed as a percentage of the total number of nodes.

If the value exceeds the threshold it is shaded red.

The saturation threshold value is configurable. Contact [email protected] for details.

Node Group Memory Saturation

Indicates whether this container resides on a node with memory utilization above the saturation threshold (default: 95%), during the past 7 days.

The saturation threshold value is configurable. Contact [email protected] for details.

% Nodes with Memory Saturation

The percentage of nodes with memory utilization above the configurable, saturation threshold (default: 0%) during the past 7 days of history. The value is expressed as a percentage of the total number of nodes. Calculated as: Node hours with saturated memory/total node hours.

If the value exceeds the threshold the cell is shaded red.

The saturation threshold value is configurable. Contact [email protected] for details.

Node Group Primary Constraint

Indicates the reason that more containers cannot be added to this node group. The following values are evaluated and whichever has the largest value is identified as the primary constraint:

• CPU Request—Based on the value of CPU Request (Capacity %)
• CPU Utilization—Based on the value of Average CPU Utilization (%)
• Memory Request—Based on the value of Memory Request (Capacity %)
• Memory Utilization—Based on the value of Average Memory Utilization (%)

Total

The totals for each column are shown in bold, at the bottom of the table. This is the total of all the records in the filtered, tabular report.

The total, listed at the bottom of the Request and Limit columns for both CPU and Memory, is calculated as (Current CPU Request * Current Count). This formula is also used for CPU Limit, Memory Request and Memory Limit.

The total, listed at the bottom of the Surplus columns for both CPU and Memory, is calculated as: (Current - Recommended).

If the value of any row is unspecified, then that value is treated as "0" when summing the values for the total.